전체 시스템 구조도 - 도메인, 참여자, 토픽

전체 시스템 구조도 - 도메인, 참여자, 토픽

DDS(Data Distribution Service) 미들웨어 아키텍처를 관통하는 핵심 사상은 ’데이터 중심(Data-Centric)’이라는 철학적 기반이다. 전통적인 클라이언트-서버 모델이나 메시지 큐(Message Queue) 시스템이 ’행위(Verb)’와 ’메시지 전송(Sending)’에 초점을 맞추었다면, DDS는 ‘명사(Noun)’, 즉 데이터 그 자체의 상태와 생명주기 관리에 모든 역량을 집중한다. 시스템 설계자는 “어떻게 메시지를 보낼 것인가“를 고민하는 대신, “어떤 데이터가 공유되어야 하며, 그 데이터는 어떤 특성을 가지는가“를 정의해야 한다. 이 장에서는 이러한 데이터 중심 아키텍처를 지탱하는 세 가지 핵심 기둥인 도메인(Domain), 도메인 참여자(DomainParticipant), 그리고 **토픽(Topic)**의 구조적 관계와 상세 메커니즘을 심층적으로 분석한다. 이들은 OMG(Object Management Group)가 정의한 DCPS(Data-Centric Publish-Subscribe) 모델의 최상위 계층을 구성하며, 물리적인 네트워크 토폴로지 위에 논리적인 데이터 공유 공간을 형성하는 기반이 된다. 1

1. 글로벌 데이터 공간 (Global Data Space)의 아키텍처

DDS 시스템의 가장 큰 특징은 **글로벌 데이터 공간(Global Data Space, GDS)**이라는 추상화된 개념을 현실 세계의 네트워크 위에 구현한다는 점이다. 애플리케이션 개발자의 관점에서 네트워크는 존재하지 않는다. 모든 참여자는 로컬 메모리에 있는 변수를 읽고 쓰는 것처럼 동작하며, GDS는 이 데이터가 시간과 공간의 제약을 넘어 필요한 곳으로 전달되도록 보장하는 거대한 ‘분산 공유 메모리(Distributed Shared Memory)’ 역할을 수행한다. 3

1.1 탈중앙화된 가상 공간의 실체

GDS는 물리적으로 중앙 집중화된 서버나 브로커(Broker)가 존재하는 공간이 아니다. 이는 분산된 각 노드(Node)들의 로컬 데이터 저장소(Local Data Store)가 RTPS(Real-Time Publish Subscribe) 프로토콜을 통해 실시간으로 동기화됨으로써 형성되는 논리적인 환영(Illusion)이다. 5 이러한 구조는 시스템에 다음과 같은 강력한 아키텍처적 특성을 부여한다.

  • 완전한 탈중앙화(Decentralization): 중앙 서버가 없으므로 단일 실패 지점(Single Point of Failure, SPOF)이 존재하지 않는다. 특정 노드가 파괴되거나 네트워크에서 이탈하더라도, GDS 자체는 붕괴되지 않으며 남은 노드들 간의 통신은 지속된다. 이는 국방, 항공우주, 전력망 제어와 같이 높은 생존성을 요구하는 미션 크리티컬 시스템에서 DDS가 채택되는 결정적인 이유이다. 6
  • 공간적 결합 제거(Space Decoupling): 정보 생산자(Publisher)는 소비자가 어디에 있는지, 몇 명인지, IP 주소가 무엇인지 알 필요가 없다. 단지 GDS에 데이터를 ’투고(Publish)’할 뿐이며, 데이터는 스스로 소비자를 찾아간다. 2
  • 시간적 결합 제거(Time Decoupling): QoS(Quality of Service) 정책, 특히 내구성(Durability) 설정을 통해 생산자가 데이터를 보낸 시점에 소비자가 부재중이라도, 추후 소비자가 GDS에 접속하는 즉시 과거의 데이터를 받아볼 수 있다. 이는 GDS가 단순한 전송 채널이 아니라, 데이터의 상태를 보존하는 저장소임을 의미한다. 3

1.2 데이터 중심성과 관계형 모델

GDS 내에서 데이터는 단순한 비트의 나열(Payload)이 아니다. 데이터는 명확한 타입(Type)과 구조, 그리고 키(Key)를 가진 구조화된 정보이다. 7 이는 관계형 데이터베이스(RDBMS)의 테이블(Table) 개념을 네트워크 공간으로 확장한 것과 유사하다.

  • Topic: 데이터베이스의 테이블 이름에 해당한다.
  • Instance: 테이블의 각 행(Row)에 해당하며, Primary Key로 식별된다.
  • Sample: 특정 행의 값이 시간에 따라 변화하는 업데이트 내역이다.

DDS 미들웨어는 이 데이터 모델을 기반으로 필터링, 정렬, 수명 관리 등을 수행하며, 애플리케이션 로직이 처리해야 할 데이터 관리의 복잡성을 인프라 스트럭처 레벨로 흡수한다. 8

2. 도메인 (Domain): 통신의 논리적 격벽과 우주

GDS가 전역적인 데이터 공유의 장이라면, **도메인(Domain)**은 이 거대한 우주를 논리적으로 분할하는 가장 강력한 격벽(Partition)이다. 하나의 물리적 네트워크 인프라 위에서 서로 다른 목적을 가진 시스템들이 간섭 없이 공존해야 할 때, 도메인은 필수적인 격리 수단을 제공한다. 9

2.1 도메인 ID와 격리 메커니즘

도메인은 Domain ID라고 불리는 양의 정수(Integer)로 식별된다. DDS 사양은 도메인 ID와 물리적 네트워크 포트 매핑 간의 관계를 정의하여, 서로 다른 도메인 ID를 사용하는 애플리케이션들이 네트워크 레벨에서부터 서로를 감지하지 못하도록 설계했다. 4

구분설명아키텍처 효과
식별자Domain ID (정수, 예: 0, 1, 42)논리적 네트워크 구분
발견(Discovery)도메인별로 서로 다른 멀티캐스트 주소 및 포트 사용트래픽 원천 차단
데이터 공유동일 도메인 내의 참여자끼리만 가능보안 및 간섭 방지
리소스도메인별 독립적인 데이터베이스 유지관리의 독립성 보장

물리적으로 같은 스위치, 같은 서브넷, 심지어 동일한 메모리를 공유하는 컴퓨터 내에서 실행되더라도, 도메인 0에 있는 ’항법 시스템’과 도메인 1에 있는 ’무기 제어 시스템’은 서로의 존재를 전혀 인식하지 못한다. RTPS 프로토콜의 발견(Discovery) 단계에서 사용되는 포트 계산 공식에 도메인 ID가 포함되기 때문에, 패킷 자체가 서로의 소켓에 도달하지 않거나 필터링된다. 10

2.2 다중 도메인 아키텍처와 브리지 패턴

대부분의 애플리케이션은 단일 도메인에 참여하는 것이 일반적이지만, 시스템 통합(System Integration) 관점에서는 하나의 프로세스가 복수의 도메인에 접속해야 하는 경우가 발생한다. 이를 도메인 브리지(Domain Bridge) 패턴이라고 한다. 12

  • 보안 게이트웨이: 외부 네트워크와 연결된 ’공용 도메인’과 내부의 민감한 데이터를 다루는 ‘보안 도메인’ 사이에서 데이터를 선별적으로 중계하는 역할을 한다.
  • 계층적 제어: 빠른 주기의 실시간 제어 데이터가 흐르는 ’제어 도메인’과, 대용량의 로그 및 모니터링 데이터가 흐르는 ’관리 도메인’을 분리함으로써, 모니터링 트래픽이 제어 주기에 영향을 주는 것을 방지한다.
  • 이종 프로토콜 연동: 도메인별로 서로 다른 전송 계층(UDPv4, Shared Memory, TCP 등)을 설정하여, 로컬 통신은 공유 메모리로 고속 처리하고 원격 통신은 UDP로 처리하는 식의 하이브리드 구성을 취할 수 있다. 12

이때 주의할 점은 도메인이 다르면 데이터 타입이나 토픽 이름이 같아도 전혀 다른 개체로 취급된다는 점이다. 도메인 A의 “Position” 토픽과 도메인 B의 “Position” 토픽은 이름만 같을 뿐, 서로 간섭하지 않는 별개의 데이터 스트림이다. 13

3. 도메인 참여자 (DomainParticipant): 시스템의 앵커이자 팩토리

**도메인 참여자(DomainParticipant)**는 애플리케이션이 특정 도메인에 입장을 허가받았음을 나타내는 멤버십의 증명서이자, 그 도메인 내에서 통신을 수행하기 위한 모든 자원의 컨테이너(Container)이다. 14 UML 모델상 DomainParticipant는 Entity 클래스를 상속받으며, 도메인 내의 모든 발행/구독 객체들을 생성하고 소유하는 최상위 팩토리(Factory) 역할을 수행한다. 9

3.1 계층적 팩토리 패턴 (Hierarchical Factory Pattern)

DDS의 모든 엔티티 생성은 엄격한 부모-자식 관계를 따르는 팩토리 패턴으로 설계되어 있다. 개발자는 new 연산자로 객체를 직접 생성할 수 없으며, 반드시 상위 팩토리 객체의 생성 메서드를 호출해야 한다. 15

  1. DomainParticipantFactory (Singleton): 프로세스 내에 유일하게 존재하는 팩토리의 팩토리이다. create_participant() 메서드를 통해 DomainParticipant를 생성한다. 이 객체는 싱글톤이므로 전역적인 QoS 설정이나 스레드 설정을 관리한다. 17
  2. DomainParticipant: 도메인에 연결된 후, Topic, Publisher, Subscriber를 생성한다. 15
  3. Publisher / Subscriber: 실제 데이터 송수신을 담당하는 DataWriter와 DataReader를 생성한다. 16

이러한 계층 구조는 **생명주기 관리(Lifecycle Management)**에 있어 강력한 이점을 제공한다. 상위 엔티티인 DomainParticipant를 삭제(delete_participant)하면, DDS 미들웨어는 재귀적으로 그 하위의 모든 퍼블리셔, 서브스크라이버, 토픽, 그리고 라이터와 리더들을 안전하게 정리하고 메모리를 해제한다. 이는 복잡한 분산 시스템 코드에서 발생하기 쉬운 자원 누수(Resource Leak)나 댕글링 포인터(Dangling Pointer) 문제를 아키텍처 레벨에서 예방한다. 16

3.2 리소스 컨테이너로서의 역할

DomainParticipant는 단순한 논리적 객체가 아니라, 실제 통신을 수행하기 위해 무거운 시스템 리소스를 점유하는 단위이다. 일반적으로 하나의 참여자를 생성할 때마다 다음과 같은 리소스가 할당된다. 11

  • 네트워크 포트: 데이터 송수신을 위한 유니캐스트/멀티캐스트 소켓.
  • 스레드 풀(Thread Pool): 수신 패킷 처리를 위한 리시버 스레드, 이벤트 처리를 위한 비동기 스레드, 재전송을 위한 타이머 스레드 등이 참여자별로 독립적으로 생성된다. 22
  • 디스커버리 데이터베이스: 도메인 내의 다른 참여자, 라이터, 리더들의 존재를 추적하고 상태를 관리하는 내부 테이블.
  • 메모리 버퍼: 데이터 직렬화/역직렬화 및 송수신 큐를 위한 메모리 공간.

따라서 불필요하게 많은 DomainParticipant를 생성하는 것은 시스템 성능, 특히 스레드 컨텍스트 스위칭 오버헤드와 메모리 사용량에 악영향을 미칠 수 있다. 원칙적으로 물리적으로 분리된 네트워크 인터페이스를 사용하거나, 논리적으로 완전히 격리해야 하는 요구사항이 없다면, **“하나의 프로세스에는 도메인당 하나의 참여자만 생성한다”**는 원칙을 준수해야 한다. 11

3.3 기본 QoS 설정과 전파 (Default QoS Provider)

대규모 시스템에서 수백 개의 DataWriter와 DataReader가 생성될 때, 각각의 QoS를 일일이 설정하는 것은 오류를 유발하기 쉽다. DomainParticipant는 하위 엔티티들이 사용할 기본 QoS(Default QoS)를 저장하고 관리하는 중앙 저장소 역할을 한다.

개발자는 set_default_publisher_qos, set_default_topic_qos 등의 API를 사용하여 참여자 레벨에서 표준 정책을 정의할 수 있다. 하위 엔티티 생성 시 DATAWRITER_QOS_DEFAULT와 같은 상수를 인자로 넘기면, 참여자에 설정된 기본값이 자동으로 적용된다. 이는 시스템 전체의 통신 정책 일관성을 유지하는 데 핵심적인 기능을 수행한다. 9

4. 토픽 (Topic): 데이터 연결의 매개체

토픽(Topic)은 DDS 내에서 정보의 흐름을 연결하는 가장 기본적인 단위이다. 발행자와 구독자는 서로의 신원(Identity)을 알 필요 없이, 오직 ’토픽’을 통해서만 느슨하게 결합된다. 토픽은 발행자가 “무엇을 이야기할 것인가“를 정의하고, 구독자가 “무엇을 듣고 싶은가“를 선언하는 계약(Contract)이다. 14

4.1 토픽의 구성: 이름과 타입의 이중주

DDS 표준에서 토픽은 반드시 **토픽 이름(Topic Name)**과 **데이터 타입(Data Type)**의 쌍으로 정의된다. 24

  1. 토픽 이름: 도메인 내에서 유일한 문자열 식별자이다. (예: “Aircraft/Position”, “Sensor/Temp”). 계층적 구조를 표현하기 위해 슬래시(/)를 사용하는 것이 관례이나, 미들웨어 입장에서는 단순한 문자열일 뿐이다.
  2. 데이터 타입: 해당 토픽이 운반하는 데이터의 구조적 정의(Schema)이다. OMG IDL(Interface Definition Language)로 정의되며, 언어 중립적인 구조체(Struct) 형태를 띤다. 1

통신이 성립하기 위해서는 토픽의 이름뿐만 아니라 데이터 타입까지 완벽하게 일치(또는 호환)해야 한다. 예를 들어, 발행자가 “Velocity“라는 이름으로 Vector3 타입을 보내는데, 구독자가 같은 이름으로 float 타입을 기다린다면, DDS의 발견(Discovery) 매커니즘은 이를 ’타입 불일치(Inconsistent Type)’로 간주하여 연결을 거부한다. 이는 런타임에 발생할 수 있는 데이터 해석 오류(예: 메모리 오염, 비정상적인 값 처리)를 원천적으로 방지하는 강력한 타입 안전성(Type Safety)을 제공한다. 2

4.2 토픽 객체의 관리: 생성과 조회

토픽 역시 DomainParticipant를 통해 생성된다. 그러나 시스템 통합 과정에서 이미 생성된 토픽 정의를 재사용해야 하는 경우가 빈번하다. 이를 위해 DDS는 두 가지 접근 방식을 제공한다.

  • create_topic(): 새로운 토픽을 생성한다. 만약 이미 동일한 이름과 타입의 토픽이 존재한다면, 기존 토픽 객체를 반환하거나(구현에 따라 다름) 오류를 반환한다. 생성 시에는 TopicQos를 인자로 받아, 이 토픽이 가져야 할 기준 품질을 설정한다. 19
  • find_topic(): 이미 도메인 내에(정확히는 로컬 참여자의 지식 내에) 정의된 토픽을 이름으로 조회한다. 이는 주로 구독자 측에서, 발행자가 정의한 토픽 정보를 바탕으로 DataReader를 생성하려 할 때 유용하게 사용된다. 단, find_topic은 일정 시간 동안 토픽 정보가 발견될 때까지 대기(Blocking)할 수 있는 타임아웃 파라미터를 가진다. 26

이때 주의할 점은, find_topic이나 create_topic을 통해 얻은 토픽 객체의 참조 카운트 관리이다. 일부 구현체에서는 find_topic으로 얻은 객체라도 사용이 끝나면 대칭되는 delete_topic 등을 호출하여 리소스를 반환해야 할 수도 있다. 26

5. 키(Key)와 인스턴스(Instance): 데이터 식별의 심화

DDS가 단순한 메시징 시스템을 넘어 ‘데이터 중심’ 미들웨어로 불리는 가장 결정적인 이유는 바로 **키(Key)**와 **인스턴스(Instance)**의 개념에 있다. 이는 관계형 데이터베이스의 Primary Key 개념을 실시간 분산 시스템에 도입하여, 데이터 스트림을 세밀하게 관리할 수 있게 한다. 27

5.1 토픽, 인스턴스, 샘플의 위계 관계

DDS를 처음 접하는 개발자가 가장 혼동하기 쉬운 세 가지 개념의 관계를 명확히 해야 한다. 27

개념RDBMS 비유설명예시
토픽 (Topic)Table데이터의 종류와 구조(Type)를 정의하는 틀FlightTrack (항공기 추적 정보)
인스턴스 (Instance)Row키(Key) 값으로 식별되는 고유한 실체(Object)FlightTrack 중 Flight ID가 “KAL001“인 객체
샘플 (Sample)Update Log특정 인스턴스의 특정 시점의 값(Value)“KAL001“의 10:00:01 시점 위치 좌표

5.2 키(Key)의 정의와 역할

IDL을 작성할 때 구조체의 특정 필드에 @key 어노테이션(또는 별도의 Key 정의 구문)을 사용함으로써 키를 지정할 수 있다.

struct SensorData {
@key string sensor_id; // 고유 식별자 키
long timestamp;
float value;
};

위의 예에서 sensor_id가 키로 지정되면, DDS는 sensor_id가 같은 데이터들은 동일한 센서에서 발생한 연속적인 업데이트로 간주하고, sensor_id가 다르면 완전히 별개의 센서 데이터로 취급한다. 이를 통해 하나의 SensorData 토픽만으로 수천 개의 센서 데이터를 구별하여 처리할 수 있다. 만약 키가 정의되지 않은 토픽이라면, 그 토픽은 전역적으로 단 하나의 인스턴스(Singleton Instance)만을 가지는 것으로 간주된다. 29

5.3 인스턴스 생명주기 (Instance Lifecycle) 상태 머신

DDS는 인스턴스 단위로 정교한 상태 머신(State Machine)을 관리한다. 이는 미들웨어가 단순히 데이터를 전달하는 파이프라인이 아니라, 데이터의 존재 유무를 관리하는 관리자임을 보여준다. DataReader는 데이터 샘플과 함께 SampleInfo라는 메타데이터를 수신하며, 이를 통해 인스턴스의 상태 변화를 감지한다. 28

  1. ALIVE: 인스턴스가 생성되었고, 최소 하나 이상의 DataWriter가 활성 상태로 이 인스턴스를 업데이트하고 있는 상태이다.
  2. NOT_ALIVE_NO_WRITERS: 이 인스턴스를 업데이트하던 모든 DataWriter가 연결을 끊거나 종료되었지만, 데이터 자체는 시스템에서 명시적으로 삭제되지 않은 상태이다. 이는 데이터 제공자가 일시적으로 사라진 상태를 의미하며, Ownership QoS와 결합하여 ’Failover(장애 조치)’를 구현하는 데 사용된다.
  3. NOT_ALIVE_DISPOSED: DataWriter가 dispose() API를 호출하여 “이 데이터 객체는 더 이상 유효하지 않음“을 선언한 상태이다. 예를 들어, 항공기가 착륙하여 레이더 추적에서 사라지거나, 태스크가 완료되어 더 이상 모니터링할 필요가 없을 때 사용된다. 31

이러한 상태 정보는 응용 프로그램 레벨에서 별도의 ’종료 메시지’나 ’Heartbeat’를 구현하지 않아도, 미들웨어 차원에서 객체의 생성과 소멸을 완벽하게 동기화할 수 있게 해 준다.

5.4 리소스 관리와 인스턴스

인스턴스 사용은 메모리 관리 측면에서도 중요한 의미를 가진다. DataWriter와 DataReader는 각 인스턴스별로 별도의 캐시와 QoS 정책(예: History depth)을 유지한다. 따라서 키의 카디널리티(Cardinality, 가능한 키 값의 수)가 매우 높다면(예: 무한히 증가하는 난수를 키로 사용), 리소스 제한 QoS(ResourceLimits QosPolicy)를 적절히 설정하여 메모리 고갈을 방지해야 한다. 30 DataWriter 설정 중 autodispose_unregistered_instances 옵션을 활용하면, 라이터가 인스턴스 관리를 중단할 때 자동으로 폐기(Dispose) 메시지를 보내 리소스를 정리하도록 할 수 있다. 31

6. 전체 구조의 종합적 이해

지금까지 분석한 도메인, 참여자, 토픽, 그리고 인스턴스의 관계를 종합하여 시스템 전체의 구조를 조망하면 다음과 같다.

  1. 격리된 우주(Domain): 시스템의 최상위에는 논리적으로 격리된 도메인들이 존재한다.
  2. 진입점(Participant): 각 애플리케이션 프로세스는 DomainParticipant를 통해 특정 도메인에 접속하며, 이때 필요한 네트워크 리소스와 스레드가 할당된다.
  3. 데이터 정의(Topic): 참여자는 Topic을 통해 도메인 내에서 통용될 데이터의 이름과 타입을 정의한다.
  4. 객체 식별(Instance): 정의된 토픽은 Key에 의해 수많은 인스턴스로 실체화된다.
  5. 상태 관리: DDS 미들웨어는 각 인스턴스의 생명주기(Alive, Disposed 등)를 추적 관리하며, 이를 GDS를 통해 모든 구독자에게 동기화한다.

이러한 계층 구조는 DDS가 단순한 통신 라이브러리를 넘어, 분산 시스템을 위한 ’데이터 백본(Data Backbone)’으로 기능하게 하는 핵심 설계이다. 설계자는 이 구조 위에서 QoS 정책을 조합함으로써, 느슨하게 결합되면서도(Decoupled) 엄격하게 관리되는(Managed) 고성능 분산 시스템을 구축할 수 있다. 다음 절에서는 이 구조 위에서 실제로 데이터를 생산하고 소비하는 주체인 Publisher와 Subscriber의 구체적인 역할과 데이터 흐름 제어에 대해 다룰 것이다.

7. 참고 자료

  1. About the Data Distribution Service Specification Version 1.4, https://www.omg.org/spec/DDS/1.4/About-DDS
  2. Data Distribution Service (DDS) - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.4/PDF
  3. What is DDS? - DDS Foundation, https://www.dds-foundation.org/what-is-dds-3/
  4. What Is DDS? - MATLAB & Simulink - MathWorks, https://www.mathworks.com/help/dds/gs/dds-conceptual-overview.html
  5. 1.1.1. The DCPS conceptual model - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/getting_started/definitions.html
  6. The DDS Global Data Space. | Download Scientific Diagram - ResearchGate, https://www.researchgate.net/figure/The-DDS-Global-Data-Space_fig7_221926739
  7. Introduction to DDS (Data Distribution Service): Real-Time Data Communication Made Easy!, https://erhanbakirhan.medium.com/introduction-to-dds-data-distribution-service-real-time-data-communication-made-easy-d6f4badddd6f
  8. DDS Models simultaneously system’s Things, their Metadata, and Relationships, https://cyclonedds.io/content/blog/B2RKDDSModelThingsTheirRelationshipAndRelations.html
  9. Cyclone ISO C++ API Reference Guide: dds::domain::DomainParticipant Class Reference - GitHub Pages, https://atolab.github.io/cdds-docs/api/cxx/a01143.html
  10. Fundamentals of DDS Domains and DomainParticipants - RTI Community, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/Fundamentals_of_DDS_Domains_and_DomainPa.htm
  11. DomainParticipant in rustdds::dds - Rust - Docs.rs, https://docs.rs/rustdds/latest/rustdds/dds/struct.DomainParticipant.html
  12. Domains, participants, topics, readers and writers | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/forum-topic/domains-participants-topics-readers-and-writers
  13. Do DDS topics have to be defined the same way for every domain participant?, https://stackoverflow.com/questions/48930542/do-dds-topics-have-to-be-defined-the-same-way-for-every-domain-participant
  14. OMG Data-Distribution Service: Architectural Overview, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/DDS_Architectural_Overview.pdf
  15. 3.2.1. DomainParticipant - 3.4.1 - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/dds_layer/domain/domainParticipant/domainParticipant.html
  16. 3.3.6. Creating a DataWriter - 3.4.1 - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.4.x/fastdds/dds_layer/publisher/dataWriter/createDataWriter.html
  17. 3.2.3. DomainParticipantFactory - 3.4.1 - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/dds_layer/domain/domainParticipantFactory/domainParticipantFactory.html
  18. DDS::DomainParticipantFactory Class Reference - Twin Oaks Computing, Inc, https://www.twinoakscomputing.com/documents/refman_html_4.0.10/CoreDX_DDS_CPP_Reference_4.0.10/classDDS_1_1DomainParticipantFactory.html
  19. DDS::DomainParticipant Class Reference - Twin Oaks Computing, Inc, https://www.twinoakscomputing.com/documents/refman_html_4.0.10/CoreDX_DDS_CPP_Reference_4.0.10/classDDS_1_1DomainParticipant.html
  20. CoreDX Data Distribution Service: DDS::DomainParticipant Class Reference, https://www.twinoakscomputing.com/documents/refman_html_3.6.8/CoreDX_DDS_CPP_Reference_3.6.8/classDDS_1_1DomainParticipant.html
  21. DomainParticipant | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/glossary/domainparticipant
  22. RTI Connext C API: DomainParticipantFactory - RTI Community, https://community.rti.com/static/documentation/connext-dds/current/doc/api/connext_dds/api_c/group__DDSDomainParticipantFactoryModule.html
  23. Introduction to DDS - OpenDDS 3.28.0 - Read the Docs, https://opendds.readthedocs.io/en/dds-3.28/devguide/introduction_to_dds.html
  24. 3.5.7. Creating a Topic - 3.4.1 - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.4.x/fastdds/dds_layer/topic/topic/createTopic.html
  25. Getting Started - OpenDDS 3.34.0-dev, https://opendds.readthedocs.io/en/latest/devguide/getting_started.html
  26. 20.1.2.1. DomainParticipant - 3.4.1 - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.4.x/fastdds/api_reference/dds_pim/domain/domainparticipant.html
  27. Chapter 8 DDS Samples, Instances, and Keys, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/DDS_Samples__Instances__and_Keys.htm
    1. Reading and Writing Data — The Data Distribution Service Tutorial, https://download.zettascale.online/www/docs/Vortex/html/ospl/DDSTutorial/readandwrite.html
    1. Keys and Instances — RTI Connext Getting Started documentation - RTI Community, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/getting_started_guide/csharp/intro_keys_instances.html
  30. 3.5.1. Topics, keys and instances - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/dds_layer/topic/instances.html
  31. RTI Connext Traditional C++ API: DDS_WriterDataLifecycleQosPolicy Struct Reference, https://community.rti.com/static/documentation/connext-dds/current/doc/api/connext_dds/api_cpp/structDDS__WriterDataLifecycleQosPolicy.html
  32. 3.6. Create DataWriter — RTI Connext DDS Micro 2.4.14.0 documentation - RTI Community, https://community.rti.com/static/documentation/connext-micro/2.4.14/doc/html/gettingstarted/createdatawriter.html
  33. how to manage life cycle of topic instances manually while using qos configuration file, https://stackoverflow.com/questions/55635028/how-to-manage-life-cycle-of-topic-instances-manually-while-using-qos-configurati